As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
A new revolution is gaining momentum—a surge of innovation that involves vast ecosystems of sensors, devices, and equipment to networks that can transmit and receive data. With an estimated number of connected “things” reaching over 25 billion by 2020, the “Internet-of-Things” (IoT) is widely regarded as the next technological frontier.
Existing IoT deployments range from single device implementations to massive cross-platform systems that include tens, hundreds, or even thousands of heterogeneous devices. Tying it all together are different communication protocols that enable these various components to talk to each other.
Because IoT is still in its infancy, however, its underlying technologies remain fractured. Alliances and coalitions are being formed in hopes of someday unifying the IoT landscape. But, at the present time, there is still no central IoT standard or deployment oversight. Consumers and providers continue to face ever-increasing deployment, architecture, analytics, and security challenges.
For example, when building services in a distributed environment such as IoT, automated service discovery becomes important. Without service discovery, users or developers must manually reconfigure each service with endpoint information (e.g., URLs) for its depending services every time that information is changed.
Conventional “service discovery” services work as follows: first, a service provider registers itself onto a Service Discovery Server (e.g., Apache ZooKeeper™, HashiCorp's Consul, Netflix Open Source Platform's Eureka, Airbnb's SmartStack, etc.). The service provider may also offer endpoint information (URL), service type, service ID, etc. This information is kept on the service discovery server. Once a client needs such a service, it queries the Service Discovery Server, and retrieves the service provider's endpoint. Finally, the client can invoke the service provider based on what it just retrieved.
In an IoT and micro service architecture, an IoT Gateway queries for service endpoints of external cloud services or enterprise services on premise that it needs, and then invokes the targeted services according to the endpoint information (e.g., URL). (High-end IoT devices can have the same requirement.) These service discovery services maintain dynamic service lists and provide them to whichever node may need them, thus reducing the effort of keeping the up-to-date endpoint information of services locally.
As the inventors hereof have recognized, however, if service endpoint information is retrieved dynamically, it consumes resources and time as the requests and responses are sent back and forth between the IoT gateway and the service discovery service. Frequent requests may be sent from the IoT gateway to the discovery service, and these requests may be sent by any microservice or independent application inside the IoT gateway. For frequently-used services, the resource consumption and latency can be considerable. Moreover, the developers of micro services or applications must be familiar with the Application Programming Interface (API) of the specific service discovery solution.
As such, the inventors hereof have recognized a number of drawbacks in traditional service discovery processes, including: (1) in a highly distributed environment, each application/micro service in a node may need to make several calls over the network to discover details of services it may require. This wastes network bandwidth, time and has negative impact on latency; (2) An application or micro service is tightly coupled to a particular implementations of a Service Discovery solution. If the solution changes, the service discovery part of the client needs to be re-written to adjust to the new API, which reduces the portability of an application; and (3) developers of the applications or micro services have to learn the API of the service discovery solution they adopted. For some programming languages, such as C and C++, they need more effort to be implemented to invoke the modern API, such as REST with JSON, which is the only to communicate with some service discovery solutions.